Federated compliance mapping of disparate content management systems

ABSTRACT

A federated compliance management system operating in a cloud computing environment imports a repository-specific retention policy from a source information system operating in an enterprise computing environment and converts, using a policy mapping definition, the repository-specific retention policy into a federated retention policy. The policy mapping definition contains attribute mappings for federated attributes common across a plurality of information systems of disparate types, repository-specific attributes that are specific to an information system, and, where applicable, phase-common attributes that are common for all phases of an information system as well as phase-repository-specific attributes that are configured for a specific phase. The federated retention policy is stored in the cloud computing environment for use by the federated compliance management system, for instance, as a base policy for creating a repository-specific retention policy for a target system.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application claims a benefit of priority under 35 U.S.C. § 119(e)from Provisional Application No. 63/273,776, filed Oct. 29, 2022,entitled “FEDERATED COMPLIANCE MAPPING OF DISPARATE CONTENT MANAGEMENTSYSTEMS,” which is fully incorporated by reference herein for alpurposes.

TECHNICAL FIELD

This disclosure relates generally to compliance management. Moreparticularly, this disclosure relates to systems, methods, and computerprogram products for hybrid onboarding of compliance systems throughcentralized federated compliance management utilizing tenant-specificpolicy mapping definitions.

BACKGROUND OF THE RELATED ART

Currently, a Federated Compliance (FC) service can track anorganization's records and manage content retention and metricsregardless of the repository type to provide an enterprise with insightinto the enterprise's information governance.

To fetch the compliance data from on-premises (“on-prem”) systems, aconventional approach involves fetching data from a Restful Web service(REST) application programming interface (API) into a federatedcompliance system backend service. Attributes thus retrieved are thenevaluated by mapping them to respective FC attributes in the sourcecode. The mapped, converted metadata attributes are stored into adatastore. If data consists of multiple phases, then the data needs tobe relatively mapped to join tables in data stores in case of arelational database.

This conventional approach is how most of today's FC services integratetheir APIs between services. A producer service provides the API withresponse payload and a consumer service reads this content through apre-defined/hard coded object structure.

If an enterprise needs to migrate compliance policies (e.g., policiesgoverning content retentions/holds) from one information system toanother information system, the enterprise would need to re-create thecompliance policies in the new information system. This is a verytedious and time taking process. Also, if the enterprise is managingmultiple information systems, it is not possible to have and manage thesame retention/hold policy for all the information systems.

Accordingly, the conventional approach discussed above has the followingdrawbacks:

-   -   It is not possible to have and manage the same policy        (retention/hold) for different information systems.    -   Migrating policy (retention/hold) data from one to another        information system is a tedious task.    -   Switching to a new content service needs a huge amount of manual        effort.    -   Every information system will have different retention metadata,        hence source code must be placed to support each type. This        means that the federated compliance service will grow huge.    -   If any new properties are introduced, updated, or deleted, then        the federated compliance service would need to update its source        code to adopt these changes.    -   Maintaining multiple information systems with federated        compliance is a complex process.    -   Dynamically mapping the attributes cannot be performed.

In view of the foregoing, there is room for innovations and improvementin federated compliance management.

SUMMARY OF THE DISCLOSURE

Hybrid onboarding support is essential for FC services, as a FC serviceneeds to perform compliance data import, read, and write operations withmultiple types of information systems. Each information system usuallyhas its own retention/hold attributes for managing records storedtherein. These retention/hold attributes are unique to each individualsystem and can have multiple phases. Further, mapping of on-premretention or hold metadata objects to FC retention or hold metadata iscomplex and can involve multiple phases.

A goal of this disclosure is to provide a new approach to FC applicationand services. In some embodiments, this goal is realized in a FCmanagement system operating on a cloud computing platform. The cloudcomputing platform, referred to herein as the “cloud,” includes acloud-based software as a service (SaaS) applications layer thatprovides various web-based software, on-demand software, and/or hostedsoftware as services. These services enable organizations and enterprisealike to leverage existing on-prem, cloud, or hybrid platform resources,as well as information stored in different repositories, to quicklyextend existing solutions to the cloud. The FC management system has anenhanced retention policy service where federated retention policies arestored and an enhanced compliance service where tenant-specific policymapping definitions are stored.

In some embodiments, the new approach includes the following features:

-   -   Using a policy mapping definition, one information system        attribute can be mapped to another information system        dynamically.    -   Better control from the perspective of tenant administration as        the policy mapping definition is tenant-specific, hence tenants        can have respective unique mappings for different attributes.    -   Retention/hold policies for multiple on-prem information systems        can be centrally managed using policy mapping definition files        in the FC management system.    -   Policy mapping definitions can be reconciled to pick up new        fields automatically whenever the compliance service is        bootstrapped, allowing on-the-fly attributes to be        created/changed if any changes occur in an information system.    -   Policy mapping definition supports the attributes to be defined        at global/system-specific/phase levels, providing a desired        flexibility for categorization (user experience).    -   A user interface (UI) of the FC management system renders all        the fields based on the policy mapping definition metadata that        contains attributes, drop-lists and conditions.    -   Conditions can be set to evaluate the data type in the target        information system.    -   Policy mapping definition provides an ability to define a        repository mapping field and base mapping for other content        server fields as well as default fields.    -   Repository field mapping for every attribute provides a        connection with on-prem information system data. By using this,        the compliance service can import the data and write the data to        the information system.    -   Policy mapping definition supports localization for labels.    -   Versioning support for the policy mapping definition is also        available for each information system.    -   Provisioning a new information system (e.g., a document        management system (DMS), content server (CS), content management        system (CMS), information archive (IA) system, etc.) is much        easier by creating a new policy mapping definition.

In some embodiments, a method of federated management of repositoriesmay comprise, at a central management server, defining a centralrepository retention policy and defining a plurality of managedrepository retention policies associated with the central repositoryretention policy, each of the managed repository retention policieshaving a repository type selected from a plurality of repository types,each of the managed repository retention policies having repositoryattributes. Specifically, each of the managed repository retentionpolices can be associated with an instance of a repository and values ofthe repository attributes of each of the managed repository retentionpolicies can be mapped with attributes of the associated repositoryinstance. The method may further comprise defining at least oneretention policy value of the central repository retention policy andmapping the at least one retention policy value to each of the managedrepository retention policies based on the repository type of each ofthe managed repository retention policies. The repository types cancomprise at least one of: an archival repository type, a cloud-basedrepository type, or an on-premises enterprise repository type.

In some embodiments, the managed repository retention policies cancomprise repository type common attributes defining attributes common tothe plurality of repository types, repository type specific attributesdefining attributes specific to each of the repository types, phasecommon attributes defining type phase attributes common to the pluralityof repository types, and phase specific attributes defining type phaseattributes specific to each of the repository types.

In some embodiments, defining at least one retention policy value of thecentral repository retention policy can include defining a common phaseattribute comprising a phase common attribute or a phase specificattribute and mapping the common phase attribute to at least one of thephase common attributes or at least one of the phase specific attributesof each of the managed repository retention policies.

In some embodiments, the central repository retention policy can bederived from one of the plurality of managed repository retentionpolicies. In some embodiments, the central repository retention policyhas master repository attributes inherited by each of the managedrepository retention policies and the at least one defined retentionpolicy value is a value of one of the master repository attributes.

In some embodiments, the central management server is coupled to one ormore repository servers, with the one or more repository serversmanaging the associated repository instances. The central repositoryretention policy can be updated and the update is mapped to theassociated managed repository retention policies.

In some embodiments, a method for federated compliance management maycomprise importing, by a federated compliance management systemoperating in a cloud computing environment, a repository-specificretention policy from a source information system communicativelyconnected to the federated compliance management system over a network,the source information system operating in an enterprise computingenvironment. The method may further comprise converting, by thefederated compliance management system using a policy mappingdefinition, the repository-specific retention policy into a federatedretention policy, the policy mapping definition containing attributemappings for federated attributes common across a plurality ofinformation systems of disparate types and repository-specificattributes that are specific to the source information system. In someembodiments, the source information system is multi-phased and thepolicy mapping definition may further comprise phase-common attributesthat are common for all phases of the source information system as wellas phase-repository-specific attributes that are configured for aspecific phase. The federated retention policy can be centrally storedin the cloud computing environment for use by the federated compliancemanagement system in managing, e.g., via a retention policy service, theplurality of information systems including the source informationsystem.

In some embodiments, the method may further comprise determining whetherthe repository-specific retention policy of the source informationsystem is up for migration to a target information system and,responsive to the repository-specific retention policy of the sourceinformation system being up for migration to the target informationsystem, initiating importation of all repository-specific retentionpolicies from the source information system, wherein therepository-specific retention policies are converted into federatedretention policies using the policy mapping definition.

In some embodiments, prior to the initiating the importation of all therepository-specific retention policies from the source informationsystem, the method may comprise prompting, via a user interface, a userto select for importation a repository-specific retention policy fromall the repository-specific retention policies of the source informationsystem.

In some embodiments, the method may further comprise determining thefederated retention policy converted from the repository-specificretention policy from the source information system as a base policy forcreating a repository-specific policy for a target information systemand preparing, using a policy mapping definition for the targetinformation system and values from the base policy, a payload for a call(e.g., a REST call) to the target information system, the payloadincluding information required by the target information system tocreate the repository-specific policy, and making the call with thepayload thus prepared to the target information system. In response, thetarget information system is operable to create and store therepository-specific policy locally.

In some embodiments, the policy mapping definition is provisioned to thesource information system from a master mapping definition and compliesto a common schema internal to the federated compliance managementsystem. In some embodiments, the master mapping definition comprises atemplate field for which a value is prepopulated from a template whenthe policy mapping definition is provisioned by the federated compliancemanagement system for the source information system.

In one embodiment, a system may comprise a processor, a non-transitorycomputer-readable storage medium, and stored instructions translatableby the processor to perform a method substantially as described herein.Another embodiment comprises a computer program product having anon-transitory computer-readable storage medium storing instructionstranslatable by a processor to perform a method substantially asdescribed herein.

These, and other, aspects of the disclosure will be better appreciatedand understood when considered in conjunction with the followingdescription and the accompanying drawings. It should be understood,however, that the following description, while indicating variousembodiments of the disclosure and numerous specific details thereof, isgiven by way of illustration and not of limitation. Many substitutions,modifications, additions and/or rearrangements may be made within thescope of the disclosure without departing from the spirit thereof, andthe disclosure includes all such substitutions, modifications, additionsand/or rearrangements.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings accompanying and forming part of this specification areincluded to depict certain aspects of the invention. A clearerimpression of the invention, and of the components and operation ofsystems provided with the invention, will become more readily apparentby referring to the exemplary, and therefore nonlimiting, embodimentsillustrated in the drawings, wherein identical reference numeralsdesignate the same components. Note that the features illustrated in thedrawings are not necessarily drawn to scale.

FIG. 1 is an architectural diagram that illustrates a federatedcompliance management system operating in a cloud computing environmentin communication with on-prem information systems operating in anoff-the-cloud enterprise computing environment according to someembodiments disclosed herein.

FIG. 2A depicts a flow diagram illustrating an example of a processperformed by a federated compliance management system according to someembodiments disclosed herein.

FIG. 2B depicts a flow diagram illustrating an example of anotherprocess performed by the federated compliance management system of FIG.2A according to some embodiments disclosed herein.

FIG. 3 depicts a diagrammatic representation of an example architecturehaving a central management server and a central repository retentionpolicy for federated management of repositories according to someembodiment disclosed herein.

FIGS. 4A-4C show portions of an example of a basic mapping definitionaccording to some embodiment disclosed herein.

FIGS. 5A-5C show portions of an example of a complex mapping definitionaccording to some embodiment disclosed herein.

FIGS. 6A-6E show portions of an example template that can be used topopulate fields of a policy mapping definition according to someembodiment disclosed herein.

FIGS. 7A-8 depict user interface examples of a federated compliancemanagement system according to some embodiment disclosed herein.

FIG. 9 depicts a diagrammatic representation of an example of networkeddata processing systems for implementing some embodiment disclosedherein.

DETAILED DESCRIPTION

The invention and the various features and advantageous details thereofare explained more fully with reference to the nonlimiting embodimentsthat are illustrated in the accompanying drawings and detailed in thefollowing description. Descriptions of well-known starting materials,processing techniques, components and equipment are omitted so as not tounnecessarily obscure the invention in detail. It should be understood,however, that the detailed description and the specific examples, whileindicating preferred embodiments of the invention, are given by way ofillustration only and not by way of limitation. Various substitutions,modifications, additions and/or rearrangements within the spirit and/orscope of the underlying inventive concept will become apparent to thoseskilled in the art from this disclosure. Embodiments discussed hereincan be implemented in suitable computer-executable instructions that mayreside on a computer readable medium (e.g., a hard disk drive, flashdrive or other memory), hardware circuitry or the like, or anycombination.

FIG. 1 is an architectural diagram that illustrates a FC managementsystem 110 operating in a cloud computing environment (“cloud”). In theexample of FIG. 1 , the FC management system 110 is communicativelyconnected to on-prem information systems 170, 180, 190 operating in anoff-the-cloud enterprise computing environment 160 over a secureconnection 101.

More specifically, a tunnel agent 165 operating in the off-the-cloudenterprise computing environment 160 works with a tunnel service 115 toprovide secure communications between the two computing environments.The on-prem information systems 170, 180, 190 are configured formanaging content stored in on-prem repositories. Communications for theon-prem information systems 170, 180, 190 are received by theoff-the-cloud enterprise computing environment 160 through the tunnelagent 165 and handled by an orchestrator service 163. The orchestratorservice 163 can communicate, directly or through a directory service161, with the on-prem information systems 170, 180, 190. The on-preminformation systems 170, 180, 190, which can be of different types, areconfigured for managing content stored in on-prem repositories.

In some embodiments, the FC management system 110 is configured forproviding (e.g., based on the SaaS model) a plurality of services,including a retention policy service (RPS) 111, an authenticationservice 113, and a compliance service 130. The authentication service113 is configure for authenticating users of the FC management system110. The RPS 111 and the compliance service 130 are configured forsupporting federated policy management over content stored in disparateinformation systems, including on-cloud repositories (e.g., an on-cloudrepository managed by the content management system 140) as well asoff-cloud repositories (e.g., repositories managed by on-prem systems170, 180, 190).

In some embodiments, the RPS 111 is configured for servicing requests,e.g., received via a cloud-based federated compliance (FC) application120, pertaining to management of federated retention policies centrallystored by the FC management system 110. In some embodiments, thecompliance service 130 is configured for handling attribute mapping atvarious levels (e.g., at a federated level, at a repository level, at acommon phase level, at a phase-specific level, etc.) utilizing policymapping definition 150.

In some embodiments, the FC management system 110 is embodied on amulti-tenant architecture that allows customers (e.g., enterprises) toshare computing resources as tenants. When provisioning the computingresources for a tenant (e.g., an enterprise customer), a process sets upa policy mapping definition unique to that enterprise customer based ona master mapping definition file. The master mapping definition filecontains mapping definitions for all types of repositories and how tohandle attribute mappings internally within the FC management system110. The master mapping definition file defines, for each informationsystem type, how to represent data stored in a repository to a user ofthe FC application 120. This representation can be different from tenantto tenant. For instance, a tenant may want to modify a field and/or mayonly have one or two on-prem information systems installed. Thus, apolicy mapping definition file provisioned for a particular tenant caninclude a subset of the mapping definitions contained in the mastermapping definition. As the policy mapping definition is tenant-specific,the tenants of the FC management system 110 can have respectively uniquemappings for different attributes of their information systems.

In some embodiments, from the perspective of federated compliance,attributes mapping can take place at different levels:

-   -   Federated attributes: attributes that are common for all        information systems (e.g., content management systems, content        servers, information archives, repositories, etc.);    -   Repository- or information system type-specific attributes:        attributes that are specific to a repository type or an        information system type;    -   Phase-common attributes: attributes that are common for all        phases for a given system; and    -   Phase-repository-specific attributes: attributes that are        configured for a specific phase in a particular repository or        information system.

In some embodiments, policy mapping definitions provisioned toindividual customers can be stored as part of the compliance service130. In some embodiments, customers could add fields for desiredattributes to their own policy mapping definitions. The FC managementsystem 110 may provide an interface with a functionality that allows acustomer to make a change to their policy mapping definition file sothat if an extra field is added to their repository, the complianceservice 130 is able to map the extra field to a federated policy usingthe policy mapping definition provisioned to, and edited by, thecustomer.

As a non-limiting example, a customer may wish to change the label of adata field for a particular attribute used within one of their on-preminformation systems. The customer can edit the policy mapping definitionso as to tailor their own representation on the screen (e.g., a userinterface of the FC application 120). As another example, a customer maywish to change the order in how information is shown on the screen(e.g., a drop list).

In this disclosure, a representation refers to a specific way ofrepresenting converted policies (i.e., federated policies) inside the FCmanagement system 110 so that they can be used across disparateinformation systems, including on-cloud and off-cloud repositories. Thepolicies are imported and converted into the FC management system 110using the policy mapping definition 150 provisioned for the customer. Insome embodiments, the compliance service 130 includes a converteroperable to generate a retention policy in a standard format (e.g., acommon schema) using the policy mapping definition 150. The convertercomprises code for creating a REST call required by a specificrepository to create, update, or delete a policy. The common schemasupports all repository types, so repository-specific converters areneeded to convert and prepare REST calls for individual repositoriesusing mapping definitions.

As a non-limiting example, suppose a customer has the IA 170 and the DMS180 installed on their premises and wishes to use the DMS 180 as thebasis for retention policies over the IA 170. The customer may importthe policies specific to the DMS 180 into the FC management system 110.The imported policies are converted by the compliance service 130 andstored by the RPS 110. The IA 170 can be added for FC management via theFC application 120 so that both the IA 170 and the DMS 180 have the samepolicies and can be managed the same way, even though the IA 170 and theDMS 180 are of different system types.

When a new repository (e.g., the CS 190) is added (e.g., as instructedby a user via the FC application 120) for federated retention policymanagement, the RPS 111 and the compliance 130 can be modified tosupport the new repository. This modification may entail adding amapping definition to the compliance server 130. Likewise, the RPS 111can be modified to support the new repository by adding/generating afederated retention policy applicable to the new repository to the RPS111. The RPS 111 takes the generated retention policy and stores it at acentral location (e.g., as part of the RPS 111).

In some embodiments, importation of a policy can be automated. Forinstance, a master mapping definition file can comprise a template withdefault values set (e.g., by a customer) for mapping definitions. Apolicy can be created using the default values and stored by the RPS111. The policy can then be pushed out to multiple types ofrepositories.

Below is a non-limiting example of a policy mapping definition for acontent server referred to as “OTCS”. In this example, the policymapping definition is written in JavaScript Object Notation (JSON).

{  ″name″: ″otcs_policy_mapping_definition″,  ″type″: ″POLICY″, ″repositoryType″: ″OTCS″,  ″mappingVersion″: 27, ″attributeDefinition″: {   ″attributes″: [   {    ″name″: ″name″,   ″label″: ″l10n.otcs.retention.name″,    ″type″: ″string″,   ″baseMapping ″: {     ″dctm″: ″name″,    },    ″repositoryField″:“$.content_suite.retention.title”   },   {    ″name″: ″description″,   ″label″: ″l10n.otcs.retention.description″,    ″type″: ″string″,   ″baseMapping ″: {      ″dctm″: ″ description ″,    },   ″repositoryField″: “$.content_suite.retention.desc”   }   {   ″name″: ″createdDate″,    ″label″:″l10n.otcs.attributes.createdDate″,    ″type″: ″date″,    “customField”:true,    “customFieldId”: “e0db4dd9-06b9-4ce7-bb49-8e9ef9844747”, #auto-generated by compliance service    ″baseMapping ″: {     ″dctm″:″dateOfCreation″,    },    ″repositoryField″:“$.content_suite.created_date”   },   {    ″name″:″retentionTriggerCode″,    ″label″:″l10n.otcs.attributes.retentionTriggerCode″,    “customField”: true,   “customFieldId”: “0b56e60e-00d3-47cf-98c0-38fe54ef24cd”, #auto-generated by compliance service    ″type″: ″integer″,   ″baseMapping″: {     ″dctm″: ″triggerCode″    },   ″repositoryField″:“$.content_suite.retention.codes.retention_trigger_code”    }   ]  } }

Below is a non-limiting example of a policy mapping definition for adocument management system referred to as “DCTM”:

{  ″name″: ″dctm_policy_mapping_definition″,  ″type″: ″POLICY″, ″repositoryType″: ″DCTM″,  ″mappingVersion″: 9,  ″attributeDefinition″:{   ″attributes″: [   {    ″name″: ″name″,    ″label″: ″l10n.dctm.retention.name″,    ″type″: ″string″,    ″baseMapping ″: {     ″otcs″: ″name″,    },    ″repositoryField″: “$.policy.object_name”  },   {    ″name″: ″ description ″,    ″label″: ″l10n.dctm.retention.description″,    ″type″: ″string″,    ″baseMapping″: {      ″otcs″: ″ description ″,    },    ″repositoryField″:“$.policy.summary”   }   {    ″name″: ″dateOfCreation″,    ″label″:″l10n.dctm.attributes.dateOfCreation″,    ″type″: ″date″,   “customField”: true,    “customFieldId”:“c6baad87-3459-4daa-9ad1-14a4653ae7fd”, # auto-generated by complianceservice    ″baseMapping ″: {     ″otcs″: ″createdDate″    },   ″repositoryField″: “$.policy.attributes.date_of_creation”   },   {   ″name″: ″triggerCode″,    ″label″:″l10n.dctm.attributes.triggerCode″,    ″type″: ″integer″,   “customField”: true,    “customFieldId”:“c6baad87-3459-4daa-9ad1-14a4653ae7fd”, # auto-generated by complianceservice    ″baseMapping ″: {    ″otcs″: ″retentionTriggerCode″    },   ″repositoryField″: ″$.policy.retention_trigger_code”   }  ]  } }

FIG. 2A depicts a flow diagram illustrating an example of a process 200performed by a FC management according to some embodiments disclosedherein.

In the example of FIG. 2A, the process 200 is operable to importretention/hold policies from a source information system. The complianceservice may comprise or work with a scheduler 220 for determiningwhether it is time to retrieve data (201). If so, the compliance serviceis operable to fetch the retention/hold policies from the on-premsystems (203). In some embodiments, the flow 200 may include a decisionlogic operable to determine whether an automated process applies (205).If so, the compliance service is operable to import all retention/holdpolicies from the source information system to the cloud (207). If not,a user can be prompted to select what retention/hold policy is to beimported into the cloud (208). The compliance service then can convertthe data from the on-prem format to one that complies with the commonschema, utilizing the policy mapping definition of a respectiveinformation system (209). The converted policy (or policies) can then bestored in the cloud for use by the retention policy service (211).

FIG. 2B depicts a flow diagram illustrating an example of a process 220performed by a FC management according to some embodiments disclosedherein.

In the example of FIG. 2B, the process 220 is operable to create arepository-specific policy using an imported policy as a base policy andpush the repository-specific policy to a target information system. Inthis example, the compliance service is operable to determine whether toautomatically use an imported policy as a base policy for anotherinformation system (222). If so, the imported policy (which is convertedfrom a format specific to the source information system into thestandard format internal to the FC management system) is used by the FCmanagement system as the base policy (224). If not, a user can beprompted to create a repository-specific policy for any availableinformation system (e.g., a target information system) after selectingan imported policy as the base policy (226). The compliance servicemakes use of the policy mapping definition, determines the values fromthe base policy, and makes the payload of a REST call compatible withthe target information system (228). The compliance service then makes arequest (e.g., via the REST call to create a policy) to the targetinformation system with the valid and compatible payload as required bythe target information system (230). The target information system thencreates a repository-specific policy using information from the payloadand stores the repository-specific policy locally (232).

Below is a non-limiting example of moving or migrating a 3-yearretention policy from a source information system (e.g., “otcs”) to atarget information system (e.g., “dctm”). The 3-year retention policyfor the source information system is as follows:

{  “otcs”: {   “retention”: {    “title”: “3 years retention”,   “desc”: “To be retained for 3-year period”,    “codes”: {    “retention_trigger_code”: “1”    }   },   “created_date”:“03/06/2021” }      }

Step 2. The user imports the above policy into the FC management systemutilizing a policy mapping definition. By using repository_field, itmaps source information system attributes (e.g., repository-specificattributes) into FC management system attributes (e.g., federatedattributes). Below is an example of a federated policy after themapping.

{  “name”: “3 years retention”,  “description”: “To be retained for3-year period”,  “createdDate”: “03/06/2021”,  “retentionTriggerCode”:“1” }

Step 3. The user can create a target information system policy by usingthe above-mentioned source information system policy as a base policy.Using base_mapping attribute of the policy mapping definition, thefollowing federated policy for the target information system can begenerated.

{  “name”: “3 years retention”,  “description”: “To be retained for3-year period”,  “dateOfCreation”: “03/06/2021”,  “triggerCode”: “1” }

Step 4: The above policy is processed and the structure below isgenerated. The same is pushed into the on-prem target information system(e.g., “dctm”) by the FC service.

{  “policy”: {   “object_name”: “3 years retention”,   “summary”: “To beretained for 3-year period”,   “retention_trigger_code”: “1”,  “attributes”: {    “date_of_creation”: “03/06/2021”   } }

The new approach described above has the advantage of supporting thehybrid onboarding, which enables tenants (enterprises) to manage thesame retention or hold policy across different information systems.Migrating retention/hold policies from one information system to anothercan be a smooth, streamlined process by using the FC policy mappingdefinition described above.

Also, incorporating any changes in the on-prem information systemattributes can be achieved dynamically by updating the policy mappingdefinition. If an API response payload is changed, then in runtime, thecompliance service can map to the correct fields using the policymapping definition. Using the attribute definition, user input fieldproperties like data type, view, condition, i18n, and so on, can becustomized easily. Policy mapping definitions can be created fortenants, giving them the flexibility to have their own attributemappings.

In the field of SaaS, services use APIs as their communicationmethodology for exchanging the data. Accordingly, by creating a policymapping definition to map the attributes between information systems andattribute definition to control the user experience solves a tediousprocess of on-boarding different content services.

A common, long-standing problem occurs in management of data retentionpolicies over multiple content management systems which manage and storedata across multiple life cycles. Often, an enterprise and/ororganization manages and stores data over different content managementsystems which manage and store repository data in multiple formats andtypes. Content management systems may widely differ in definedattributes, data types, and retention capabilities and functions.

Some content management systems and the repositories they manage arebuilt for fluid data management and storage capabilities and tasks.Here, content management systems are primarily designed to import,format, classify, analyze, and transform data etc. In contrast, othercontent management systems facilitate “at-rest” storage, often referredto as archival and/or secondary storage systems. Here, the primaryfunction is to store the data so that it may be recalled if needed andoften includes a disposal function where data is permanently deleted.

The inventive subject matter comprises computer and machine-drivenarchitectures, methodologies, and techniques for federated management ofdata retention policies over different data repositories. Moreover, acentral repository retention policy is defined to manage retentionpolicies for a set of distributed data repositories. The centralrepository retention policy maps data attributes and policy phasesbetween and among different repository types of the data repositories.Such mappings are applied to share and distribute retention policiesfrom a central source. Advantageously, the inventive subject matter usesa centrally managed, federated data retention policy approach thatovercomes many of the problems of retention management on disjointed,siloed data systems. Multi-format, federated mapping and centralmanagement between and among different data repositories can greatlyfacilitate a comprehensive retention strategy to comply with dataretention laws and regulations as well as corporate mandates,procedures, and data systems.

Referring now to FIG. 3 , a non-limiting embodiment of an architecture300 (and operations thereon) defines, at a central management server301, a central repository retention policy 305 for federated managementof repositories (generally designated by reference numeral 310). Managedrepository retention policies (generally designed by reference numeral315) are defined and associated with the central repository retentionpolicy 305, each having a repository type (a non-limiting example of aset of repository types is designated by reference numeral 311). Therepository types 311 are selected from a group of repository types(e.g., 311A, 311B, 311C, . . . , 311N). Non-limiting examples ofrepository types include Documentum (DCTM), Content Server, ArchiveService, and Content Management System, all manufactured by OpenTextCorporation of Waterloo, Canada. Other types of repository types may beincluded, including those from other manufacturers.

Each managed repository retention policy (e.g., 315A, 315B, 315C, up toor beyond 315N) has a set of attributes (an example of which isdesignated by reference numeral 312) based on its repository type 311and is associated with an instance of a repository 310. Here, themanaged repository retention policies 315 essentially control theretention characteristics of the associated repository instances 310. Ina non-limiting example, managed repository retention policy 315A isdefined and associated with repository instance 310A having a repositorytype TYPE1 (311A) which happens to be DCTM. Managed repository retentionpolicy 315A may be configured based on the attributes of repository typeTYPE1 311A and the values defined for repository 310A.

Managed repository retention policies 315A, 315B, 315C, 315N are“mapped” to central repository retention policy 305. In this way, aretention policy value 306 may be defined for central repositoryretention policy 305 and mapped 306A, 306B, 306C, 306N to managedrepository retention policies 315A, 315B, 315C, 315N (respectively) andmore specifically to the attributes 312 of each managed policy 315.Mapping from the central value 306 to the managed attributes 312 may beprogrammatically controlled and is determined based at least in part onthe repository type 311 of the managed repository retention policy 315.

Repository mappings may be defined and programmed for each repositorytype. It should be noted that the managed repository retention policies315 manage retention policies for the associated repositories 310. Theassociated repositories 310 are instances of repositories defined andexecuted for an enterprise and/or organization. Such instances (forexample, instance 310A) execute on servers (for example, 320) which mayinclude a cluster of servers for scaling and load-balancing.

Moreover, repository policies 315 can be said to have differentattributes 312 again, based on the repository type 311. In someembodiments, managed repository retention policies 315 compriserepository type common attributes defining attributes common to therepository types 311, and repository type specific attributes definingattributes specific to each of the repository types 311. Type commonattributes are those common to all repository types 311, such as arepository name, a repository identifier, the create-date of therepository, etc. Type specific attributes are those that are unique to arepository type 311, such as a particular repository type setting,format specific information, type versioning, etc.

Furthermore, managed repository retention policies 315 comprise phasecommon attributes defining type phase attributes common to therepository types 311, and phase specific attributes defining type phaseattributes specific to each of the repository types 311. For example, aphase common attribute may be the definition of a single phase becauseall repository types 311 have at least one phase, whereas phase specificattributes may be the definitions of multiple phases for a subset ofrepository types 311 with more than one phase.

A phase common attribute may be defined that is common to all repositorytypes 311. For example, all repositories have a notion of when data ismoved to a static storage phase, which may be referred to as a“static-storage date”. Here, the static-storage date is set in thecentral repository retention policy 305 and propagated to all the mappedrepository retention polices 315.

A phase specific attribute may be defined that is unique to a repositorytype and all the repositories of that type. As described above, sometypes have multiple phases and others a single phase. In such instances,when a multiple phase value is set in the central repository retentionpolicy 305, it is mapped to a multi-phase repository for a particularphase, whereas for a single-phase repository, it is mapped (or evenignored) to the one phase. Repository types 311 that have moretransactional capabilities may indeed have multiple phases, wherearchival repository types may have a single phase (i.e., store the data“at rest”).

Referring again to FIG. 3 , a non-limiting example of federated dataretention policy management includes both multi-phase repositories(311A, 311B) and single-phase 311C repository types mapped to centralrepository retention policy 305. Managed repository retention policy315A is associated with multi-phase repository 310A which initially hastwo phases, a first phase where data is actively managed, and a secondphase, where data is archived. Managed repository retention policy 315Cis associated with single-phase repository 310C which has a singlearchive phase.

Multi-phase repository 310A initially has two phases. Data is moved intorepository 310A at TIME0 and stored at database 332A. Initially, a firstphase 325A, at TIME0 plus 5 years (the “static-storage date”), data ismoved from database 332A to archived storage 332B at single phaserepository 310C. At a second phase 325B at TIME0 plus 10 years, data ispermanently deleted at 333. In contrast, single phase repository 310Chas a single phase, which is the same as phase 325B for the multi-phaserepository 310A, namely, deleting the data from archive storage 332B.

As part of an overall data retention strategy, a phase specificattribute is be defined for an additional phase that moves the data fromone storage to another at TIME0 plus 2 years. A new phase is added tothe central repository retention policy 305 which is propagated tomulti-phase repository 310A by adding a new phase 325C in between phase325A and phase 325B. The new phase information includes the differentstorages to move the data from 332A and to 332C. Once added, themulti-phase repository 310C will have three phases. Yet the archiverepository 310C is left unchanged because it does not recognizeinter-storage data movement. The static-storage date (i.e., TIME0 plus 5years) remains unchanged; the data will still be moved from themulti-phase repository 310A to the single-phase repository 310C at thestatic-storage date and deleted at TIME0 plus 10 years.

In some embodiments, central repository retention policy 305 has masterrepository attributes 307, such as name, identifier, create-date, etc.The master repository attributes 307 may be inherited by each of themanaged repository retention policies 315. For example, the managedrepository retention polices 315 may inherit the name and identifierfrom master attributes 307′ to properly refer to the central policy 305.

The central repository retention policy 305 may be defined using a userinterface 350 to input initial values. The central repository retentionpolicy 305 may also be based on an existing repository instance 310.Here, the retention policy of the existing repository instance serves toinitialize the central retention policy 305 and is, in a sense, a sourceretention policy. This may be useful when it is desired or needed forone of the existing repositories to serve as a master retention policy.Once tied to the central retention policy 305, changes to it may beappropriately propagated to the other repositories 310 of the enterpriseor organization.

In addition, user interface 350 may be used to setup the managedrepository retention policies 315. User interface 350 may list a set ofpotential repositories 310 of an enterprise or organization to federatewith the central repository server 301. Once a repository is selected, aset of repository attributes 312 may be initialized with the retentionvalues of the selected repository and modified as desired. Here, theattribute mappings may be referred, but the actual mappings areperformed by the central repository server 301. In still a furtherembodiment, a Retention Policy Service 360 may perform the mappings,based on mapping logic 365 stored in a database 362.

As described above, the repository types 311 may serve a variety of datalifecycle needs, desires, and/or applications. For example, a repositorytype (such as 311A and 311B) may be an enterprise-level repository typethat handles multiple users, groups, permissions, roles, policies,phases, etc. of an enterprise or organization. Yet another repositorytype 311C may be solely for data archiving. Another type 311N may beoriented toward data policy retention in the cloud and acrossdistributed systems. Yet still another may be oriented for single usersor small groups of users and smaller enterprises. Advantageously, thisfederated repository retention policy approach is highly flexible andadaptive.

FIGS. 4A-4C show portions of an example CMS policy mapping definitionwhich represents an example of a basic mapping definition. FIG. 4A showsthat the CMS policy mapping definition describes UI elements (e.g.,title, description, etc.) and how to render the UI elements. The CMSpolicy mapping definition has different sections, policy comments,individual phases, as well as information for each attribute (e.g.,type, size, screen position, etc.). There can be information about whatlanguages to use for labels, what fields are updatable, what fields arecustom, whether there is a drop list, where the values come from, etc.FIG. 4B shows template fields with values populated from a template. Thetemplate fields can be used to automatically prepopulate (e.g., whichprovider, where the data is, etc.) when a new mapping definition iscreated. FIG. 4C shows an example of a condition for when an attributeis built on another attribute when the condition is met.

FIGS. 5A-5C show portions of an example DCTM policy mapping definitionwhich represents an example of a more complex mapping definition. FIG.5A shows that a DCTM repository type can have a minimum of two phasesand up to seven phases. By contrast, the example CMS policy mappingdefinition shown in FIG. 4A defines a single phase. This means thatcontent is stored for a period of time and deleted afterwards. Likewise,an IA repository type has only a single phase as content is archived fora retention period and destroyed once the retention period ends. FIG. 5Aalso shows fields for common policy settings, policy rules, retentionsnapshots, and conditions. FIG. 5B shows an example of a drop listenabled for a custom field configured for showing retention strategyinformation. FIG. 5C shows a repository field containingrepository-specific information (e.g., a retention strategy identifier).This can be an actual field that maps to the DCTM-type repository andthat is used by the FC management system to generate the drop list.

FIGS. 6A-6E show portions of an example template that can be used topopulate fields of a policy mapping definition. FIG. 6A shows attributessuch as phase for multiple repository types (e.g., CMS, CS, DCTM, IA).FIG. 6B shows an example of where a default value can be set (e.g., theretention strategy field is set to “individual” for the DCTM repositorytype). FIG. 6C shows examples of repository-specific attributes (e.g.,under the “policyRepo” section). FIG. 6D shows examples of attributesthat apply across repositories (e.g., a retention strategy). FIG. 6Eshows examples of attributes that are common across phases. As discussedabove, attribute mapping using a policy mapping definition can beparticularly beneficial to migrating policies (e.g., compliance policiesthat govern retention/hold periods) from one information system toanother information system, even if the information systems are ofdifferent types (e.g., migrating the retention policies from acloud-based CMS system to an on-prem IA system). Using a template asdiscussed above can further streamline the creation of a policy mappingdefinition.

FIG. 7A depicts an example of a user interface of a FC managementsystem. In this example, the user interface shows a list of systems ofvarious types, including OTFI, OT2, DCTM, CS, and IA. DCTM, CS, and IAhave been discussed above. OTFI is an example of a file-basedintelligence platform that helps to identify, classify, and managefile-based content to ensure compliance. OT2 is an example of acloud-based platform that provides an on-cloud repository.

FIGS. 7B-7D show that a user of the FC management system can create,through a new retention policy creation popup window (FIG. 7C), a newfederated retention policy (e.g., “Sample 123”) with initially emptyattribute fields (FIG. 7D). The user can then begin, through a “ChooseTarget Systems” popup window (FIG. 7E), configuring the new retentionpolicy to target existing system(s). FIGS. 7E-7F show that the user canselect, from a drop list of repository types supported by the FCmanagement system (FIG. 7E) and a drop list of existing systems (FIG.7F), a target system of a particular repository type and specify thenumber of phase(s) for the target system (FIG. 7F). FIG. 7G shows aconfiguration popup window for configuring phase common attributes forthe target system. FIG. 7H shows a configuration popup window forconfiguring phase attributes that are specific to the target system. Thecomplexity of configuration steps can vary depending upon the type ofthe target system under configuration. FIG. 7I shows an example of amore complex configuration for a target system of the DCTM type.

In this way, the user can configure, for each desired target system,federated attributes (e.g., for the newly created retention policy“Sample 123”) common across disparate systems, repository- or systemtype-specific attributes, phase-common attributes for the respectivetarget system, and phase-repository-specific attributes. FIG. 7J showsan example list of target systems that can now be managed through thenewly created retention policy. FIG. 7K shows a plurality of retentionpolicies, including the newly created retention policy, that can becentrally managed via the FC management system and that can apply toinformation systems of disparate types.

In some embodiments, the FC management system also provides the abilityto add a new information system to a federated retention policy. FIG. 8shows an example of a user interface for adding a new information system(e.g., by specifying the type and the location such as the systemaddress of the new information system). Once the new information systemis added, the user can select an existing federated retention policy andselect the newly created information system as a target system to whichthe federated retention policy applies. Alternatively, the user canimport or create a new federated retention policy as discussed above andconfigure the newly created information system as a target system towhich the newly created federated retention policy applies.

FIG. 9 depicts a diagrammatic representation of an example of networkeddata processing systems for implementing some embodiment disclosedherein. In the example illustrated, network computing environment 900includes network 914 that can be bi-directionally coupled to usercomputer 912, server machine 915, and server machine 916. Server machinecan be bi-directionally coupled to persistent storage 918. Network 914may represent a combination of wired and wireless networks that networkcomputing environment 900 may utilize for various types of networkcommunications known to those skilled in the art.

For the purpose of illustration, a single system is shown for each ofuser computer 912, server machine 915, and server machine 916. However,with each of user computer 912, server machine 915, and server machine916, a plurality of computers (not shown) may be interconnected to eachother over network 914. For example, a plurality of user computers 912and a plurality of server machines 915 may be coupled to network 914.User computer 912 may include data processing systems for communicatingwith server machine 916. As a non-limiting example, a dashboard userinterface may run on user computer 912 and be communicatively connectedto a dashboard monitoring system running on server machine 916. Servermachine 916 may represent a node in an ecosystem. An ecosystem componentrunning on server machine 916 may be configured for publishing orproviding real time activity and event information to the dashboardmonitoring system running on server machine 916 as described above.

User computer 912 can include central processing unit (“CPU”) 920,read-only memory (“ROM”) 922, random access memory (“RAM”) 924, harddrive (“HD”) or storage memory 926, and input/output device(s) (“I/O”)928. I/O 928 can include a keyboard, monitor, printer, electronicpointing device (e.g., mouse, trackball, stylus, touch interface, etc.),or the like. User computer 912 can include a desktop computer, a laptopcomputer, a personal digital assistant, a cellular or smart phone, ornearly any device capable of communicating over a network. Servermachine 916 may be similar to user computer 912 and can comprise CPU960, ROM 962, RAM 964, HD 966, and I/O 968. Likewise, server machine 915may include CPU 950, ROM 952, RAM 954, HD 956, and I/O 958. Many otheralternative configurations are possible and known to skilled artisans.

Each of the computers in FIG. 9 may have more than one CPU, ROM, RAM,HD, I/O, or other hardware components. For the sake of brevity, eachcomputer is illustrated as having one of each of the hardwarecomponents, even if more than one is used. Each of computers 912, 915,and 916 is an example of a data processing system. ROM 922, 952, and962; RAM 924, 954, and 964; HD 926, 956, and 966; and database 918 caninclude media that can be read by CPU 920, 950, or 960. Therefore, thesetypes of memories include non-transitory computer-readable storagemedia. These memories may be internal or external to computers 912, 915,or 916.

Portions of the methods described herein may be implemented in suitablesoftware code that may reside within ROM 922, 952, or 962; RAM 924, 954,or 964; or HD 926, 956, or 966. In addition to those types of memories,the instructions in an embodiment disclosed herein may be contained on adata storage device with a different computer-readable storage medium,such as a hard disk. Alternatively, the instructions may be stored assoftware code elements on a data storage array, magnetic tape, floppydiskette, optical storage device, or other appropriate data processingsystem readable medium or storage device.

Those skilled in the relevant art will appreciate that the invention canbe implemented or practiced with other computer system configurations,including without limitation multi-processor systems, network devices,mini-computers, mainframe computers, data processors, and the like. Theinvention can be embodied in a computer or data processor that isspecifically programmed, configured, or constructed to perform thefunctions described in detail herein. The invention can also be employedin distributed computing environments, where tasks or modules areperformed by remote processing devices, which are linked through acommunications network such as a local area network (LAN), wide areanetwork (WAN), and/or the Internet. In a distributed computingenvironment, program modules or subroutines may be located in both localand remote memory storage devices. These program modules or subroutinesmay, for example, be stored or distributed on computer-readable media,including magnetic and optically readable and removable computer discs,stored as firmware in chips, as well as distributed electronically overthe Internet or over other networks (including wireless networks).Example chips may include Electrically Erasable Programmable Read-OnlyMemory (EEPROM) chips. Embodiments discussed herein can be implementedin suitable instructions that may reside on a non-transitorycomputer-readable medium, hardware circuitry or the like, or anycombination and that may be translatable by one or more server machines.Examples of a non-transitory computer-readable medium are provided belowin this disclosure.

ROM, RAM, and HD are computer memories for storing computer-executableinstructions executable by the CPU or capable of being compiled orinterpreted to be executable by the CPU. Suitable computer-executableinstructions may reside on a computer readable medium (e.g., ROM, RAM,and/or HD), hardware circuitry or the like, or any combination thereof.Within this disclosure, the term “computer readable medium” is notlimited to ROM, RAM, and HD and can include any type of data storagemedium that can be read by a processor. Examples of computer-readablestorage media can include, but are not limited to, volatile andnon-volatile computer memories and storage devices such as random accessmemories, read-only memories, hard drives, data cartridges, directaccess storage device arrays, magnetic tapes, floppy diskettes, flashmemory drives, optical data storage devices, compact-disc read-onlymemories, and other appropriate computer memories and data storagedevices. Thus, a computer-readable medium may refer to a data cartridge,a data backup magnetic tape, a floppy diskette, a flash memory drive, anoptical data storage drive, a CD-ROM, ROM, RAM, HD, or the like.

The processes described herein may be implemented in suitablecomputer-executable instructions that may reside on a computer readablemedium (for example, a disk, CD-ROM, a memory, etc.). Alternatively oradditionally, the computer-executable instructions may be stored assoftware code components on a direct access storage device array,magnetic tape, floppy diskette, optical storage device, or otherappropriate computer-readable medium or storage device.

Any suitable programming language can be used to implement the routines,methods, or programs of embodiments of the invention described herein,including C, C++, Java, JavaScript, HyperText Markup Language (HTML),Python, or any other programming or scripting code. Othersoftware/hardware/network architectures may be used. For example, thefunctions of the disclosed embodiments may be implemented on onecomputer or shared/distributed among two or more computers in or acrossa network. Communications between computers implementing embodiments canbe accomplished using any electronic, optical, radio frequency signals,or other suitable methods and tools of communication in compliance withknown network protocols.

Different programming techniques can be employed such as procedural orobject oriented. Any particular routine can execute on a single computerprocessing device or multiple computer processing devices, a singlecomputer processor or multiple computer processors. Data may be storedin a single storage medium or distributed through multiple storagemediums, and may reside in a single database or multiple databases (orother data storage techniques). Although the steps, operations, orcomputations may be presented in a specific order, this order may bechanged in different embodiments. In some embodiments, to the extentmultiple steps are shown as sequential in this specification, somecombination of such steps in alternative embodiments may be performed atthe same time. The sequence of operations described herein can beinterrupted, suspended, or otherwise controlled by another process, suchas an operating system, kernel, etc. The routines can operate in anoperating system environment or as stand-alone routines. Functions,routines, methods, steps, and operations described herein can beperformed in hardware, software, firmware, or any combination thereof.

Embodiments described herein can be implemented in the form of controllogic in software or hardware or a combination of both. The controllogic may be stored in an information storage medium, such as acomputer-readable medium, as a plurality of instructions adapted todirect an information processing device to perform a set of stepsdisclosed in the various embodiments. Based on the disclosure andteachings provided herein, a person of ordinary skill in the art willappreciate other ways and/or methods to implement the invention.

It is also within the spirit and scope of the invention to implement insoftware programming or code any of the steps, operations, methods,routines or portions thereof described herein, where such softwareprogramming or code can be stored in a computer-readable medium and canbe operated on by a processor to permit a computer to perform any of thesteps, operations, methods, routines or portions thereof describedherein. The invention may be implemented by using software programmingor code in one or more digital computers, by using application specificintegrated circuits, programmable logic devices, field programmable gatearrays, optical, chemical, biological, quantum or nanoengineeredsystems, components and mechanisms may be used. The functions of theinvention can be achieved in many ways. For example, distributed ornetworked systems, components, and circuits can be used. In anotherexample, communication or transfer (or otherwise moving from one placeto another) of data may be wired, wireless, or by any other means.

A “computer-readable medium” may be any medium that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, system, ordevice. The computer readable medium can be, by way of example only butnot by limitation, an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system, apparatus, system, device,propagation medium, or computer memory. Such computer-readable mediumshall be machine readable and include software programming or code thatcan be human readable (e.g., source code) or machine readable (e.g.,object code). Examples of non-transitory computer-readable media caninclude random access memories, read-only memories, hard drives, datacartridges, magnetic tapes, floppy diskettes, flash memory drives,optical data storage devices, compact-disc read-only memories, and otherappropriate computer memories and data storage devices. In anillustrative embodiment, some or all of the software components mayreside on a single server computer or on any combination of separateserver computers. As one skilled in the art can appreciate, a computerprogram product implementing an embodiment disclosed herein may compriseone or more non-transitory computer readable media storing computerinstructions translatable by one or more processors in a computingenvironment.

A “processor” includes any, hardware system, mechanism or component thatprocesses data, signals or other information. A processor can include asystem with a central processing unit, multiple processing units,dedicated circuitry for achieving functionality, or other systems.Processing need not be limited to a geographic location, or havetemporal limitations. For example, a processor can perform its functionsin “real-time,” “offline,” in a “batch mode,” etc. Portions ofprocessing can be performed at different times and at differentlocations, by different (or the same) processing systems.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having,” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,product, article, or apparatus that comprises a list of elements is notnecessarily limited only those elements but may include other elementsnot expressly listed or inherent to such process, product, article, orapparatus.

Furthermore, the term “or” as used herein is generally intended to mean“and/or” unless otherwise indicated. For example, a condition A or B issatisfied by any one of the following: A is true (or present) and B isfalse (or not present), A is false (or not present) and B is true (orpresent), and both A and B are true (or present). As used herein,including the claims that follow, a term preceded by “a” or “an” (and“the” when antecedent basis is “a” or “an”) includes both singular andplural of such term, unless clearly indicated within the claim otherwise(i.e., that the reference “a” or “an” clearly indicates only thesingular or only the plural). Also, as used in the description hereinand throughout the claims that follow, the meaning of “in” includes “in”and “on” unless the context clearly dictates otherwise.

It will also be appreciated that one or more of the elements depicted inthe drawings/figures can also be implemented in a more separated orintegrated manner, or even removed or rendered as inoperable in certaincases, as is useful in accordance with a particular application.Additionally, any signal arrows in the drawings/figures should beconsidered only as exemplary, and not limiting, unless otherwisespecifically noted.

In the foregoing specification, the invention has been described withreference to specific embodiments. However, one of ordinary skill in theart appreciates that various modifications and changes can be madewithout departing from the scope of the invention as set forth in theclaims below. Accordingly, the specification and figures are to beregarded in an illustrative rather than a restrictive sense, and allsuch modifications are intended to be included within the scope ofinvention. The scope of the disclosure should be determined by thefollowing claims and their legal equivalents.

What is claimed is:
 1. A method, comprising: importing, by a federatedcompliance management system operating in a cloud computing environment,a repository-specific retention policy from a source information systemcommunicatively connected to the federated compliance management systemover a network, the source information system operating in an enterprisecomputing environment; converting, by the federated compliancemanagement system using a policy mapping definition, therepository-specific retention policy into a federated retention policy,the policy mapping definition containing attribute mappings forfederated attributes common across a plurality of information systems ofdisparate types and repository-specific attributes that are specific tothe source information system; and storing the federated retentionpolicy in the cloud computing environment for use by the federatedcompliance management system in managing the plurality of informationsystems including the source information system.
 2. The method accordingto claim 1, further comprising: determining whether therepository-specific retention policy of the source information system isup for migration to a target information system; and responsive to therepository-specific retention policy of the source information systembeing up for migration to the target information system, initiatingimportation of all repository-specific retention policies from thesource information system, wherein the repository-specific retentionpolicies are converted into federated retention policies using thepolicy mapping definition.
 3. The method according to claim 2, furthercomprising: prior to the initiating the importation of all therepository-specific retention policies from the source informationsystem, prompting, via a user interface, a user to select forimportation a repository-specific retention policy from all therepository-specific retention policies of the source information system.4. The method according to claim 1, further comprising: determining thefederated retention policy converted from the repository-specificretention policy from the source information system as a base policy forcreating a repository-specific policy for a target information system;preparing, using a policy mapping definition for the target informationsystem and values from the base policy, a payload for a call to thetarget information system, the payload including information required bythe target information system to create the repository-specific policy;making the call with the payload thus prepared to the target informationsystem, wherein the target information system creates and stores therepository-specific policy.
 5. The method according to claim 1, whereinthe policy mapping definition is provisioned to the source informationsystem from a master mapping definition and complies to a common schemainternal to the federated compliance management system.
 6. The methodaccording to claim 1, wherein the master mapping definition comprises atemplate field for which a value is prepopulated from a template whenthe policy mapping definition is provisioned by the federated compliancemanagement system for the source information system.
 7. The methodaccording to claim 1, wherein the source information system ismulti-phased and wherein the policy mapping definition further comprisesphase-common attributes that are common for all phases of the sourceinformation system and further comprises phase-repository-specificattributes that are configured for a specific phase.
 8. A federatedcompliance management system, comprising: a processor; a non-transitorycomputer-readable medium; and instructions stored on the non-transitorycomputer-readable medium and translatable by the processor for:importing a repository-specific retention policy from a sourceinformation system communicatively connected to the federated compliancemanagement system over a network, the federated compliance managementsystem operating in a cloud computing environment, the sourceinformation system operating in an enterprise computing environment;converting, using a policy mapping definition, the repository-specificretention policy into a federated retention policy, the policy mappingdefinition containing attribute mappings for federated attributes commonacross a plurality of information systems of disparate types andrepository-specific attributes that are specific to the sourceinformation system; and storing the federated retention policy in thecloud computing environment for use by the federated compliancemanagement system in managing the plurality of information systemsincluding the source information system.
 9. The federated compliancemanagement system of claim 8, wherein the instructions are furthertranslatable by the processor for: determining whether therepository-specific retention policy of the source information system isup for migration to a target information system; and responsive to therepository-specific retention policy of the source information systembeing up for migration to the target information system, initiatingimportation of all repository-specific retention policies from thesource information system, wherein the repository-specific retentionpolicies are converted into federated retention policies using thepolicy mapping definition.
 10. The federated compliance managementsystem of claim 8, wherein the instructions are further translatable bythe processor for: prior to the initiating the importation of all therepository-specific retention policies from the source informationsystem, prompting, via a user interface, a user to select forimportation a repository-specific retention policy from all therepository-specific retention policies of the source information system.11. The federated compliance management system of claim 8, wherein theinstructions are further translatable by the processor for: determiningthe federated retention policy converted from the repository-specificretention policy from the source information system as a base policy forcreating a repository-specific policy for a target information system;preparing, using a policy mapping definition for the target informationsystem and values from the base policy, a payload for a call to thetarget information system, the payload including information required bythe target information system to create the repository-specific policy;making the call with the payload thus prepared to the target informationsystem, wherein the target information system creates and stores therepository-specific policy.
 12. The federated compliance managementsystem of claim 8, wherein the policy mapping definition is provisionedto the source information system from a master mapping definition andcomplies to a common schema internal to the federated compliancemanagement system.
 13. The federated compliance management system ofclaim 8, wherein the master mapping definition comprises a templatefield for which a value is prepopulated from a template when the policymapping definition is provisioned by the federated compliance managementsystem for the source information system.
 14. The federated compliancemanagement system of claim 8, wherein the source information system ismulti-phased and wherein the policy mapping definition further comprisesphase-common attributes that are common for all phases of the sourceinformation system and further comprises phase-repository-specificattributes that are configured for a specific phase.
 15. A computerprogram product for federated compliance management, the computerprogram comprising a non-transitory computer-readable medium storinginstructions translatable by a processor of a federated compliancemanagement operating in a cloud computing environment for: importing arepository-specific retention policy from a source information systemcommunicatively connected to the federated compliance management systemover a network, the source information system operating in an enterprisecomputing environment; converting, using a policy mapping definition,the repository-specific retention policy into a federated retentionpolicy, the policy mapping definition containing attribute mappings forfederated attributes common across a plurality of information systems ofdisparate types and repository-specific attributes that are specific tothe source information system; and storing the federated retentionpolicy in the cloud computing environment for use by the federatedcompliance management system in managing the plurality of informationsystems including the source information system.
 16. The computerprogram product of claim 15, wherein the instructions are furthertranslatable by the processor for: determining whether therepository-specific retention policy of the source information system isup for migration to a target information system; and responsive to therepository-specific retention policy of the source information systembeing up for migration to the target information system, initiatingimportation of all repository-specific retention policies from thesource information system, wherein the repository-specific retentionpolicies are converted into federated retention policies using thepolicy mapping definition.
 17. The computer program product of claim 15,wherein the instructions are further translatable by the processor for:prior to the initiating the importation of all the repository-specificretention policies from the source information system, prompting, via auser interface, a user to select for importation a repository-specificretention policy from all the repository-specific retention policies ofthe source information system.
 18. The computer program product of claim15, wherein the instructions are further translatable by the processorfor: determining the federated retention policy converted from therepository-specific retention policy from the source information systemas a base policy for creating a repository-specific policy for a targetinformation system; preparing, using a policy mapping definition for thetarget information system and values from the base policy, a payload fora call to the target information system, the payload includinginformation required by the target information system to create therepository-specific policy; making the call with the payload thusprepared to the target information system, wherein the targetinformation system creates and stores the repository-specific policy.19. The computer program product of claim 15, wherein the policy mappingdefinition is provisioned to the source information system from a mastermapping definition and complies to a common schema internal to thefederated compliance management system.
 20. The computer program productof claim 15, wherein the source information system is multi-phased andwherein the policy mapping definition further comprises phase-commonattributes that are common for all phases of the source informationsystem and further comprises phase-repository-specific attributes thatare configured for a specific phase.